[レポート]Amazon Aurora の技術とイノベーションDeep dive(AWS-39) #AWSSummit

#Amazon Aurora

#AWS

たかやま

2024.06.21

こんにちは。たかやまです。

現在開催中のAWS Summit Japan 2024で行われた「Amazon Aurora の技術とイノベーションDeep dive」のレポートをお伝えします。

動画/資料も公開されましたので、ぜひご覧ください！

セッション概要

タイトル : Amazon Aurora の技術とイノベーションDeep dive

Amazon Aurora は、ストレージとコンピューティングを分離する革新的なアーキテクチャと、グローバルデータベースや低レイテンシーのリードレプリカなどの高度な機能を備えており、リレーショナルデータベースのあり方を再構築します。 Aurora は、オープンソースの MySQL および PostgreSQL との完全な互換性を備え、比類のないパフォーマンスと大規模な高可用性を提供する最新のデータベースサービスです。このセッションでは、Aurora I/O-Optimized、Aurora zero-ETL と Amazon Redshift の統合、Aurora Serverless v2 など、Aurora が提供する新機能について詳しく説明します。 pgvector 拡張機能の追加により、ベクター埋め込みの保存と生成 AI のベクター類似性検索のサポートがどのように可能になるかについても紹介します。

スピーカー : 塚本真理

セッションレベル : 400

レポート内容

Auroraの基本

アーキテクチャ
- Auroraストレージとレプリカ -可用性と耐久性
- Auroraストレージは3AZに分散される
- ライター
  - 最低2AZに書き込みを行うことで完了とする
  - ひとつの1AZ障害に耐久性あり
  - 読み込みはブロックごと
- リードレプリカ
  - Auroraストレージをアタッチするだけで拡張が可能
  - (RDSはそのままインスタンスを複製する形をとる)
  - 15インスタンスまで拡張可能
  - インスタンスサイズは異なっても問題なし
  - インスタンス障害時はリードレプリカに自動で切り替わる
  - 通常プロパゲーションは時間が掛かる
  - AWS JDBCを利用することで最大66%プロパゲーションの時間を削減することができる
Amazon Aurora Global Database
- リージョン間でデータをDRする仕組み
- 設定を有効化するだけで簡単にDRを提供する
- Global Databaseを有効化すると裏側でレプリケーションサーバが立ち上がる
- レプリケーションサーバはユーザー管理不要
- DRの仕組みはレプリケーションサーバにデータを転送する
- セカンダリーDBでリードレプリカを追加することでアプリケーション利用も可能
- 切り替えは2パターン
- Switchover
  - 検証のユースケースで利用する
  - switchoer-global-clusterコマンドを使う
  - スイッチオーバー後はレプリケーション逆方向になる
- Failover
  - 障害時に利用する機能
  - failover-global-clusterコマンドを使う
  - オプション--allow-data-lossはレプリケーションサーバでデータ欠損を起こしている可能性がある場合でもフェイルオーバーする機能
  - 始めにプライマリがリードレプリカになりスナップショットをとる
  - フェイルオーバー時に移行できなかったデータはスナップショットから復元する
  - その後、セカンダリーが昇格してプライマリになる
Global Database Write Forwarding
- セカンダリクラスターでも書き込みが可能になる機能
- 従来はアプリケーションでトンネルを開け同期処理検討する必要があったがそこをオフロードできる
- セカンダリーの書き込みはプライマリへ、プライマリの書き込みをセカンダリに送られる

管理性の向上に役立つ機能

Serverless v2
- CPU/メモリリソースを追加し1秒以内に自動的にスケールする機能
- パフォーマンスインサイトを用いたワークロード例を紹介
- DB load過多 : DBloadが20に対しMax vCPUsが4.xlargeの16で不足している状態
  - こういった状態を改善するのがAurora Serverless
  - Serverlessの場合、負荷に合わせて設定された最大ACU(128)の8%ずつスケールアップする
- IO待機の発生
  - IO待機が発生時は平均レイテンシも10倍に増加している
  - この時DBload22でMax vCPUs 16でDBload過多も起こしている
  - Aurora Serverlessを利用することでEstimated vCPUsで予測することがわかる
  - 実際にAurora Serverlessを利用することでレイテンシーを1/8に抑えることができる
Amazon Aurora Managed Blue/Green Deployment
- Blue Greenを利用することで短いダウンタイムでできる
- 例としてMySQL 5.7->8.0へアップデートする
- crate-blue-green-deploymentを利用することでターゲットが作成される
- 最初は同じバージョンでターゲットが作成され、その後メジャーアップデート処理が行われる
- ステータスがavailableになればswitchover-blue-green-deploymentで切り替えができる
- 切り替え中のステータスはSWITCHOVER_IN_PROGRES
- 切り替えが完了するとステータスはSWITCHOVER_COMPLETED
  - インスタンス名も自動でかわる
- delete-blue-greppn-deploymentでBlue/Green環境を削除する
  - このコマンド自体では旧クラスターは削除されずBlue/Green環境と切り離される感じになる
  - 旧クラスターは動作が安定するまで持っておき、安定稼働したら手動で削除する
RedshiftとのAuroraゼロETL
- 大規模トランザクション分析
- 通常のETL処理には複雑なアーキテクチャ(DMS/S3/Glue...)が必要になる
- そこで利用できるのがゼロETL統合
  - ペタバイト規模のトランザクションデータに対してほぼリアルタイムで分析が可能
  - AuroraとRedshiftのストレージ間でのレプリケーションを行っている
  - 分析ワークロードを検討している場合に利用できる

新しいストレージタイプとOptimized Reads

Aurora I/O Optimized
- コストの予測がしやすく、I/O負荷の高いワークロードにおいてコストパフォーマンスが向上する機能
- コンピューティング/ストレージはStandardより高いが、I/Oについてはコストなし
- StandardのIO合計支出がAuroraデータベースの合計支出25%を超えた場合にコストパフォーマンスが向上する
- 制約事項
- I/O Optimizedはクラスターストレージ構成
- 月に1回ストレージオプション(標準 -> I/O最適化)に変更できる
  - いつでももとに戻せる
- Aurora PostgreSQL 13.x 以降 / Aurora MySQL 3.0.3.1 以降で利用可能
- ワークロードの性能においてもメリットがある
- I/Oが多くインスタンスが大きくなるほどI/O Optimizedのメリットがでる
- ワークロードによっては差があるが試していただく価値はある
Optimized Reads
- 通常ローカルストレージボリュームはEBSによってバックアップされておりメモリ溢れが発生した場合、EBSとの接続のレイテンシーが発生する
- Optimized Reads - 一時オブジェクト
- Auroraストレージ内にNVMeストレージが用意され、メモリ溢れが発生した場合のレイテンシーを改善する
- 対象
  - インスタンス : db.r6gd / db.r6id
  - PostgreSQL : 14.9+, 15.3+
- Optimized Reads - 階層型キャッシュ
- I/O Optimizedで利用できるOptimized Readsの機能
- 階層型キャッシュを利用することでキャッシュメモリのメタデータを管理することができる

pgvector拡張機能

Aurora PostgreSQLで利用できる生成AIに活用できるベクトル型を提供するオープンソースの拡張機能
- Aurora PostgreSQL 15.3+, 14.8+, 13.11+, 12.15+でサポート
- GitHub : https://github.com/pgvector/pgvector
pgvectorでできること
- 距離探索
- 距離演算子
- ストレージ
- ベクトルデータ型
- インデックス作成
- IVFFLAT / HNSW インデックスをサポート
- 検索
- 完全最近傍法(KNN)
- 近似最近傍(ANN)
- メタデータ
- 埋め込みと同じ場所に配置
使い慣れたPostgreSQLをAIで利用できる。
AWSが提供するRAG、Knowledge bases for Amazon Bedrock のナレッジベースとしても利用できる
実際の利用例
- Building AI-powered search in PostgreSQL using Amazon SageMaker and pgvector | AWS Database Blog
さらに階層型キャッシュを利用することでベクトルのパフォーマンスを上げることができる
- QPSが最大9倍のパフォーマンス向上が可能